COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	%\magnification=1200
C00003 00003	\centerline{A Note on Scaling Binary Typeface Information}
C00016 ENDMK
C⊗;
%\magnification=1200
\font\Z=manfnt
\font\BAS=BASL30
\font\BSC=BSCALE
\def\META{{\Z METAFONT}} 
\def\teX{\null\kern1.5pt\TeX}
\parskip 10pt plus 1pt
\parindent=0pt
\pageno=1
\BAS
\centerline{A Note on Scaling Binary Typeface Information}
\centerline{by}
\centerline{Arthur L. Samuel}

This is a report on some work directed toward developing a relatively fast
method of translating a library of 200 pixels per inch typeface fonts into
font files that are usable at 300 pixels per inch or alternately at 384
pixels per inch. The necessary code has also been generated
for translating the font files into the newer GF format and for generating
the related TFM files.  This note was printed using a font, BASL30, that
has been through this process. The output is hardly comparable in quality
with the output produced by using METAFONT generated fonts or with fonts
otherwise directly designed for use at 300 pixels per inch but at least,
as one typographer remarked, "It is readable".

The major concern in this note is to explain the method adopted for
altering the resolution.  Although an older program, FSCALE, was already
available for effecting the desired translation, it has been possible to
improve on its speed and to achieve a somewhat higher quality output.  The
number of fonts involved and the their limited initial resolutions made it
impractical to apply one of the more precise methods that have been
described in the literature.

First, a word about the two bounding methods that have been used for
altering the resolution of font files.  The better of the two
methods starts with an attempt to reconstruct a continuous image from the
samples provided by the input data. This is then sampled at the desired
resolution. Cubic splines are commonly used for the initial continuous
image generation and the entire process can be quite demanding in terms of
the computation times. At the other extreme, which incidentally works
better for reductions in resolution rather than for increases, are methods
that arbitrarily remove some points of the array or introduce additional
points as required and assign zeros or ones to them as dictated by their
neighbors.

The FSCALE program, referenced above, follows a variation of this second
course. Its action can best be understood by envisioning the superposition
of the two array of points at the two different resolutions with values of
zero or one (white or black) assigned to each point of the input array.
The conversion process then consists of assigning zeros or ones to each of
the points in the output array based on the quantized weighted average of
the values assigned to the neighboring points of the input array. Using
only the value of the nearest neighbor would, of course be the fastest
procedure but this would lead to a very poor quality ouput. FSCALE adopts
the course of referencing the four nearest neighbors.

The FSCALE method does a surprisingly good job but it suffers from one
crucial defect when dealing with changes in resolution as large as 300/200.
This defect comes about because of its failure to take advantage of the
fact that it is dealing with typefaces that follow certain typographic
conventions where the exact treatment to be accorded to any specific
region can depend upon conditions at some distance from the actual point
in question.

There are two contrasting situations that regularly occur, the one where
two different strokes join at approximately right angles and where one
does not want to soften the abruptness of the change of direction and the
second situation, most often encountered with diagonal strokes, where one
would like to take advantage of the increased resolution to smooth the
jagged approximation that was the best that could be done at the lower
resolution.  Using the framework provided by an older font manipulating
program called FMUNGE and by adding two new commands, it has been possible
to implement a method that is both faster and, in most cases, better than
FSCALE in handling these contrasting situations.

The resolution changing commands function as follows:

The program first stretches the glyph in the horizontal direction by
adding extra points between every other pair of the original points for
the 300/200 case or between every pair of points for the 400/200 case
which is used to approximate the 384/200 needed for the DOVER printer.  If
the two neighboring points are both black, the newly introduced point is
set black otherwise it is set white.  This is satisfactory for much of the
region but it assigns white to all of the new points that lie on the
glyph's borders. The program then attends to these points by referencing
a template that identifies these border points and that differentiates
between the two possible states either where the program should make this
point black to smooth the edge or where the abruptness in the change of
direction should be preserved. This template referencing is done for a
full word (36 bits) at a time, so this part of the work is done very
rapidly.

The program then stretches the glyph in the vertical direction by
introducing extra lines using vertical rules similar to those used in the
horizontal direction and finally it again references a template in
assigning values to the newly created ambiguous points.

This routine functions remarkedly well in most cases although it can also
fail rather badly on some glyphs so that hand tailoring is sometimes
needed.  In general, the resulting glyphs are somewhat lighter, that is,
have thinner strokes, than those produced by the FSCALE program but this
is usually to be preferred since the IMAGEN printer, on which the
300-pixel fonts are to be used, tends to print rather heavily.  The
program also produces a printable star/dot file that can be hand edited
with the system editor before it is transcribed to its desired final form.

All of the necessary routines to do the scaling and to produce star/dot
files and to reconvert these files into GF format are contain in the most
recent version of the FMUNGE program on SAIL.  An older FNTPL program
(requiring a 10 answer to one question) has been updated to be consistant
with the present requirements of PLtoTFM progam that is then usable to
produce a compatable TFM file. A DO file, DO FNTFIX[X,ALS], handles all of
the necessary details except for the final assigning and renaming of the
files to the [300,SYS], [384,SYS], [GF,SYS], and [TEX,SYS] directories.

The FMUNGE file is reasonably well documented, type READ FMUNGE on SAIL
for details.  In addition, R FMUNGE produces a split screen when used at
a DD terminal with a condensed listing of the more frequently used
commands on the top half the screen. This is a convenience, since it was not
possible to assign mnemonically related code letters for the three new commands.

The following fonts are currently available for general use, in .FNT form
on [300,SYS], in .300 GF form on [GF,SYS], and with the metrics in .TFM form
on [TEX,SYS] :\ \ \
	QUUX25, BASL30, BASL35, BAXM30, MATH30, SUB,
	SUP, 	FIX25, 	NGR30, 	GRKB30, ZERO30.
Other fonts will be made available as requested.

\vfill
\eject

JMC

You may be interested.

By way of comparison the attached note was produced using the 300 pixel GF
form of BASL30 with TeX. There seems to be no margin trouble here.

Incidentally, I would like your comments on this first draft which
explains the new method of scaling fonts.

The program has not actually been put up on [csp,sys] and [1,3] as
indicated but it is believed to be ready for this final step, that is
unless your trouble seems to indicate the need for some sort of fix.

als
\bye